add logging for upload queue processing (WP-1014) - #629

…ently (WP-1014)

Code review on PR #629 found that the "cleanup" commit had silently reverted
DebugTrait::shutdownHandler back to its original buggy blacklist implementation
and deleted its test file, undoing the false-fatal-report fix described in the
PR itself. Restored both from the original fix commit.

Also fixes upload queue review finding: when a queue row groups submissions for
the same content across multiple target locales and one submission's locale
can no longer be resolved, the whole row was deleted but only logged - resolved
sibling submissions were left in New status with no queue row and no error.
dequeue() now keeps checking every submission in the group instead of stopping
at the first failure, and sets a visible error message on every submission that
still exists once the group is discarded.

- UploadJob: catch \Throwable (not just \Exception) around the upload
  dispatch, matching processCloning() and actually delivering the
  crash-resilience this queue rework is meant to provide.
- UploadJob: complete() the claimed queue item when no active profile
  is found, instead of leaving it claimed until it's retried into a
  misleading "terminated unexpectedly" failure.
- UploadJob: processCloning() now dispatches through
  WordpressFunctionProxyHelper::do_action(), matching
  processUploadQueue() and making it mockable in tests.
- UploadQueueManager: build the stale-claim WHERE fragment via
  ConditionBlock/Condition instead of raw sprintf ordinals, and
  extract the duplicated fail-and-delete logic into
  discardQueueItem().
- SubmissionUploadTest: complete() dequeued items in the drain loop,
  since dequeue() now claims rows instead of deleting them and count()
  no longer drops on its own.
- Add UploadJobTest coverage for the \Throwable catch, the
  no-active-profile completion, and the proxied cloning dispatch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

… (WP-1014)

- UploadJob::processUploadQueue() now catches failures from
  getOrCreateJobInfoForDailyBucketJob(), matching the crash-safety
  pattern already used for the settings profile lookup: log, record
  the error on the submission, complete the queue item, and continue
  instead of leaving the claimed row stuck and aborting the cron run.
- DebugTrait declared FATAL_ERROR_TYPES/ERROR_TYPE_NAMES as trait
  constants, which PHP only allows from 8.2 onward, causing
  "Traits cannot have constants" fatal errors on this project's
  target PHP 8.0. Converted both to private static methods.

…lure (WP-1014)

processUploadQueue() only logged/errored the first submission in a queue item
when the profile lookup or daily bucket job creation failed, then deleted the
whole row. Any sibling submission grouped in the same item (same content,
other target locale) vanished silently: no error, no log line, stuck in New
forever. Both catch blocks now loop over every submission in the item.

Migration260825's ADD COLUMN also failed for any site still on a schema
version below 240315: Migration240315 recreates the table with
CREATE TABLE IF NOT EXISTS from the live, current
UploadQueueEntity::getFieldDefinitions(), which already includes the new
claimed/attempts columns, so the later unconditional ALTER TABLE hit a
duplicate-column error and never recorded itself as applied. The migration
now checks SHOW COLUMNS first and only adds what's actually missing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…(WP-1014)

PR #629 review comment (PavelLoparev, 3863741398): delete()'s $this->db->query()
result was never checked. wpdb::query() returns false on failure (deadlock,
lock-wait timeout, connection blip) without throwing, so a failed DELETE inside
discardQueueItem() went unnoticed: dequeue()'s while loop would continue,
re-select the exact same still-present row, and discard it again - spinning on
it forever within a single dequeue() call.

- delete() now returns bool.
- discardQueueItem() returns bool and logs when the delete didn't happen;
  both call sites in dequeue() return null instead of continuing the loop
  when a discard fails to actually remove the row.
- complete() logs (but doesn't otherwise react) on a failed delete: the row
  simply stays claimed and is picked up by the existing stale-claim retry
  path, so no special handling is needed there beyond visibility.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

PR #629 review comment (PavelLoparev, 3863741379): claim()'s $this->db->query()
result was never checked. wpdb::query() returns false on failure without
throwing, so a silently failed claim let dequeue() hand out an UploadQueueItem
whose row a second dequeue($blogId) call was still free to claim - dispatching
the same content for translation twice.

claim() now returns bool; dequeue() returns null instead of returning the item
when the claim can't be confirmed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>